Test Results

   765 files  ±0     765 suites  ±0   54m 3s ⏱️ - 3m 33s
 3 611 tests ±0   3 556 ✅  - 1   54 💤 ±0  1 ❌ +1 
10 834 runs  ±0  10 670 ✅  - 1  163 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit 23ec76f. ± Comparison against base commit 512b94b.

♻️ This comment has been updated with latest results.

@ruspl-afed for the build-failure see #1419.

Thanks @HannesWell ! After rebasing, everything turns green.
I'm going to merge it if there's no objection.

On the other hand one can start scrolling and lose it

Yes, this is exactly the case, see #1417

Either The selected package is or The selected packages are: .

I tried this approach in the very beginning and found that we have very limited horizontal space and it is better to avoid all the words except package name itself. And also, section doesn't support \n in description, so I cannot enumerate packages in the readable form of the vertical list

Please advice how to proceed better.

It took me some time to figure whats changed, as I would have expected the information of selected packages (if we want to duplicate that information) would be shown somewhere at the section list on the left.

Beside that I'm not sure if it is a good think, just in your example select all packages and it will become very crowded... I also wonder what is the underlying use case to select some packages and then scroll them out of view to afterwards show them on a different place.

In any case I would probably for artificially use-case more go like this:

1. If there is only one package selected, show a text like The package <package> is (to further read the check boxes "public API" or "provisional API")
2. If there are more than one, show a text like The packages are (to further read the check boxes "public API" or "provisional API") where packages is a link that shows a tooltip text with all selected packages, clicking on the link can bring up a dialog with a checkbox list where I can view and probably change the selection.

Thank you for your comment @laeubi , it turns me back to the question how I came to this artificial use case.
Here is the scenario:

1. There is a bundle with many packages. Well not so many, but more than 10 is enough for my setup.
2. Another package added to the bundle, with a name that puts it to the end of the list.
3. Then one decides to export this new package and opens the MANIFEST.MF editor on Runtime tab
4. With "Add..." button the "new" package is added and selected, but the list is not scrolled to make it visible (may be this is the real issue!)

Thanks Christoph for your suggestion. I wanted to suggest basically the same but got distracted and forgot to answer. Sorry for that.

2. If there are _more than one_, show a text like `The packages are` (to further read the check boxes "public API" or "provisional API") where `packages` is a link that shows a tooltip text with all selected packages, clicking on the link can bring up a dialog with a checkbox list where I can view and probably change the selection.

I fully support suggestion 1, but in suggestion two, opening a dialog that changes the selection is too much. I would simply stick with an (enhanced) simple label in case multiple packages are selected: The selected packages are.
Tbh. before this issue I wasn't really aware that one can even select multiple packages so I think this is a special case. And for a single package the situation would still be improved.

Is that what you meant? @HannesWell @laeubi

Single selection:

Multiple selection:

@ruspl-afed single selection looks fine for me, multi selection should be something like "the selected packages are" where you probabbly set a tooltip text to show the actual list because otherwise if you select say 10 or more package I fear it would somehow explode the available space.

@ruspl-afed do you plan to continue with that?

@ruspl-afed do you plan to continue with that?

Generally yes, but I need to restore context